Hi @NF0T — thanks for the FreeDV Reporter dialog, that's a great addition. 👋

I dug into the failing Qt Accessibility Static Analysis check on 12cb723b and the good news is it's a CI workflow bug, not anything in your code.

What I checked

Ran tools/check_a11y.py locally against the files this PR touches:

$ python3 tools/check_a11y.py \
    src/gui/FreeDvReporterDialog.cpp src/gui/FreeDvReporterDialog.h \
    src/gui/FreeDvReporterModel.cpp src/gui/FreeDvReporterModel.h \
    src/gui/MainWindow.cpp src/gui/MainWindow.h

=== AetherSDR accessibility check summary ===
Files scanned      : 6
Files with findings: 0
Total findings     : 0
No accessibility issues found.

Exit 0, zero findings. The "Comment with accessibility summary" sub-step on the failed run is also marked skipped (its if: is gated on findings != '0'), which confirms the linter agrees: nothing to flag here.

Why the step still failed

Bug is in .github/workflows/a11y-check.yml:

COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")
echo "findings=$COUNT" >> $GITHUB_OUTPUT

When there are zero warnings, grep -c prints 0 and exits 1. The || echo "0" then runs and prints 0 again. Command substitution captures both, so $COUNT is the two-line string 0\n0 (verified locally: xxd shows 30 0a 30). The next line writes

findings=0
0

…to $GITHUB_OUTPUT. The runner reads findings=0 fine (which is why the comment step was correctly skipped), but the stray 0 line has no name=value separator and trips the runner's "Unable to process file command" validation, failing the step.

A one-liner fix would be COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || true) — true produces no extra stdout, so $COUNT stays a clean 0. Worth a separate PR / issue against the workflow file (the tooling was added in a8bafc7 / #3289).

Bottom line for this PR

• The a11y workflow comment explicitly says "Findings are warnings only — the build is not blocked" — this check isn't gating merge.
• Your code passes the linter (0 findings).
• The other jobs (build, check-macos, check-windows, analyze (cpp)) were still in progress when I looked — those are the ones to watch.

Nothing for you to change here. Sit tight on the other checks. 73 and thanks for contributing!

_{🤖 aethersdr-agent · cost: $22.2425 · model: claude-opus-4-7}

Rebased your branch onto current main (`5e0e0d32`) to pick up #3442's a11y workflow fix. Your code didn't trigger any a11y findings — the lint scanned 6 files and reported 0 findings, then the workflow step crashed writing the result to `$GITHUB_OUTPUT`.

What the failing run actually showed

```
=== AetherSDR accessibility check summary ===
Files scanned : 6
Files with findings: 0
Total findings : 0
No accessibility issues found.
##[error]Unable to process file command 'output' successfully.
##[error]Invalid format '0'
```

Root cause

The pre-#3442 workflow had:
```bash
COUNT=$(grep -c "^::warning" /tmp/a11y_output.txt || echo "0")
```

When `grep -c` finds zero matches it exits 1 and prints `0` to stdout, so `|| echo "0"` appended a second `0`, making `COUNT=$'0\\n0'`. The next line `echo "findings=$COUNT" >> $GITHUB_OUTPUT` wrote a two-line value that the GITHUB_OUTPUT parser rejected with `Invalid format '0'` — and the step failed even though the lint had already succeeded.

#3442 fixed this by changing `|| echo "0"` to `|| true`, so `COUNT` ends up as just `0` on the zero-findings case. Timing: your CI run was 2026-06-06 19:41 UTC, #3442 merged 2026-06-06 21:44 UTC — your run hit the workflow file from your branch (workflows run from PR-branch state on `pull_request` events), which was pre-fix.

What I did

Same maintainer-fix-up pattern as #3279/#3286/#3289/#3381/#3391/#3397/#3398/#3417 — rebased your single commit onto current main, no content changes. Verified locally on Arch Linux x86: full `AetherSDR` build clean (634/635, only the pre-existing unrelated `macDaxDriverInstalled` warning).

CI will rerun against the new HEAD. Happy to revert any piece you'd rather take a different cut at.

Principle XI.